LinuC-1 - 102試験 - 1.10:セキュリティ - 1.10.3 暗号化によるデータの保護

Last Update : August 21 2022 17:47:13

     

a. OpenSSH

OpenSSH は、SSH プロトコルを使用するネットワーク接続ツールです。OpenSSH はパスワードを含むすべての通信を暗号化し、盗聴やネットワーク接続の乗っ取り、 その他の攻撃を効率的に排除します。 また、OpenSSH は安全なトンネリング機能や多様な認証方式を備えており、 すべてのバージョンの SSH プロトコルをサポートしています。

OpenSSH はクライアント ("ssh" コマンド) と サーバデーモン ("sshd" プログラム) の組み合わせを基本とします。 それぞれ「使う人」と「使われ方」につぎのような差異があります。
管理者が sshd デーモンをインストールおよび設定し、クライアントのログインを待ち受けます。
一般ユーザが ssh コマンド (クライアント) をつかってログインし、 シェルやファイル転送、ポート転送、VPN などの機能を利用します。
一般ユーザがクライアントを用いてサーバにログインを試みると、 クライアントとサーバデーモンの間で 2 種類の認証が交わされます:

  1. ホスト認証・・・そのサーバが本当に「ユーザのログインしたいサーバ」であるかどうかを確認する処理。
  2. ユーザ認証・・・そのユーザがサーバにログインする許可を持つかどうかを確認する処理。

1. ホスト認証 : なりすましを防ぐしくみ

通常はなりすましが起こらないよう、 クライアントはサーバに接続した瞬間に、まず暗号化された通信を介してそのサーバのホスト鍵 (host key) を確認し、 それが本当に自分のログインしたいサーバであるかどうか確かめます。 ホスト鍵はホスト公開鍵とホスト秘密鍵に分かれており、 クライアント上には通常 known_hosts と呼ばれるファイルがあり、 ここには特定の IPアドレス (とホスト名) をもつサーバのホスト公開鍵が登録されています。 ホスト秘密鍵はサーバマシン内のディスクに格納されており、 ネットワーク上に持ち出されることはありません。
クライアントは、まずこの known_hosts ファイル内に登録されているホスト公開鍵と、 サーバから送られてくるホスト公開鍵を照合し、 サーバが実際にこのホスト公開鍵に対応するホスト秘密鍵をもっているかどうか確認します。 この確認には公開鍵暗号技術が使われており、 サーバは実際のホスト秘密鍵をネットワーク上に送信することなく、ホスト秘密鍵の所有をクライアント側に証明できるようになっています。

サーバがホスト秘密鍵を実際にネットワーク上に送信しないにもかかわらず その所有を証明できるのは、秘密鍵と公開鍵の間にある数学的な性質のためです。 秘密鍵と公開鍵は「公開鍵暗号」と呼ばれる暗号技術の一種をもとに設計されており、 たとえば RSA 公開鍵暗号は以下のような特徴をもっています。

  • 秘密鍵で暗号化されたデータは、それに対応する公開鍵によってのみ正しく復号できる。
  • 公開鍵で暗号化されたデータは、それに対応する秘密鍵によってのみ正しく復号できる。

ホスト認証は通常 (最初の 1回目を除いて) クライアントによって自動的に行われます。 ホスト認証を行うためには、クライアントはログインする先のホスト公開鍵をあらかじめ知っている必要があります。 ところが、あるホストに初めてログインする場合、そのホスト公開鍵はまだ known_hostsファイルには登録されていません。 そのため、クライアントはサーバが送ってきたホスト公開鍵の指紋 (fingerprint) をユーザに提示し、 これが本当にユーザの接続したいサーバのものであるかどうか確認を求めるのです。 一般的にあるデータの「指紋」とは、そのデータの特徴をあらわすように 作られた短い文字列や数値のことをさします。もしホスト公開鍵が何者かによって改ざんされていれば、 その指紋は違った値になるはずなので、改ざんが判明します。 なお OpenSSH で「鍵の指紋」という場合、それはすべて公開鍵の指紋を意味します。

ここでホスト公開鍵の指紋が正しければ yes と答えます。 するとクライアントはこのホスト公開鍵を known_hosts ファイルに サーバの名前 dontcare.example.com とあわせて記録し、2回目以降の照合に使います。 [脚注: したがって、サーバの sshd をアップデートするさい、 以前と同じホスト鍵をそのまま使用することは非常に重要です。 ホスト鍵を変えてしまうと、ユーザの目には何者かがそのホストになりすましているように 見えてしまいます。] いっぽう、何者かがそのサーバになりましている場合、 その第三者はサーバの IP アドレスを詐称することができても、ホスト秘密鍵までは詐称できません。 したがってそのマシンが送ってきたホスト公開鍵を見れば、なりすましが判別できます。


2. ユーザ認証のしくみ

クライアントが正しいサーバを確認したら、つぎはサーバのほうが 正しいユーザかどうかを確認する番です。これをユーザ認証といいます。 OpenSSH のユーザ認証には大きく分けて 2つの方式があります。

  • パスワード認証 : ユーザがあらかじめ登録したパスワードを使った認証
  • 公開鍵認証 : ユーザがあらかじめ登録した秘密鍵・公開鍵ペアを使った認証

どちらもユーザがある特定の (そのユーザにしか知りえない) 情報をもっているかどうかを確認することによって、そのユーザがログインできるかどうかを判断しています。 なお、OpenSSH ではここで挙げたパスワード認証と公開鍵認証のほかに、 Hostbased認証と呼ばれるユーザ認証の方式がサポートされています。


a. パスワードを使ったユーザ認証

パスワード認証は、通常の Linux のログインに使うのと同じように、パスワードをユーザが入力し、 それによって本人かどうかを確認する方法です。 OpenSSH ではユーザの入力したパスワードは暗号化されますから、 ホスト認証が正しく完了していれば安全にログインできます。
しかし、パスワード認証では、たとえ暗号化されているとはいえユーザはパスワードを相手のマシンに教えなければならないので、ユーザは、なりすましによるパスワードの盗難のように第一回目のログインでうっかり第三者にパスワードを漏らしてしまう危険性があります。 また、最近では世界中の SSH サーバに対してパスワードをしらみつぶしに推測する攻撃が発生しているので、推測されやすい (弱い) パスワードを使っているユーザは アカウントを乗っ取られる危険性もあります。


b. 秘密鍵・公開鍵ペアを使ったユーザ認証

そこで、パスワード認証のかわりに普及してきているのが公開鍵認証です。 パスワード認証と違う点は、

  • パスワード (あるいはそれに類する秘密の情報) が一切ネットワーク上に流れない。
  • かわりにユーザは秘密鍵と公開鍵を作成し、 その公開鍵をサーバにあらかじめ登録しておく。
  • ログイン時にはサーバに自分の秘密鍵の所有を示すことでユーザの身分を証明する。ただし、この時に秘密鍵そのものは送信しない。
  • 秘密鍵がユーザのクライアントから持ち出されたり、送信されることはない。 また、サーバ上の公開鍵から秘密鍵を推測することはできない。

公開鍵認証の場合、サーバへのログインは次のようにして行われます。
事前準備として、秘密鍵と公開鍵のペアを作成します。 ssh 接続の場合だと、秘密鍵は接続する側で使用し、公開鍵は接続される側が使用することになります。 つまり、鍵ペアーを作成するのは ssh クライアント側です。 そして、作成した鍵ペアの公開鍵をサーバー側に事前に送っておきます。

  1. クライアントがサーバに接続して認証が始まる。
  2. クライアントは、自分がサーバー側に渡した公開鍵に対応する秘密鍵を持っていることを宣言する。
  3. サーバはサーバ側で作成した確認メッセージを、事前に持っているクライアントの公開鍵で暗号化してクライアントに送信する [公開鍵で暗号化したメッセージ → クライアント](チャレンジ)。
  4. クライアントは、自分の秘密キーを使えるようにするためパスフレーズを入力し、その秘密鍵で受け取った暗号文(チャレンジ)を復号化する。そして復号化した確認メッセージをサーバーに返す (レスポンス)。
  5. 正しいレスポンスが送られてくると、 サーバはユーザが秘密鍵を持っていることを確信し、ログインを許可する。

公開鍵認証の特徴は、パスワードや秘密鍵などの 「一度知られたら何度でも自分のかわりにログインされてしまう情報」が いっさいネットワーク上に流れないことです。もっとも、この場合もユーザは パスワードに相当するパスフレーズをキーボードから入力する必要がありますが、この情報はクライアント上で秘密鍵を使用するときにだけ使われ、 ネットワーク上に送信されることはありません。秘密鍵は通常、暗号化されてディスク上に格納されており、 ユーザ認証のときのみパスフレーズによって復元されます。
すべてのユーザが公開鍵認証を使うようになればパスワード認証を禁止でき、 その結果セキュリティは飛躍的に向上します。もっとも、この場合も 「なりすまし」を防ぐことはできませんが、たとえ「なりすまし」が行われた場合でも、 パスワードが盗まれるということはありません。また公開鍵認証を使うと認証エージェントが使えるため、ユーザにとっても便利です。


c. 認証エージェントを使った認証

OpenSSH では上の 2つの認証方式に加えて 「認証エージェント (authentication agent)」 によるユーザ認証をサポートしています。認証エージェントとは ユーザにかわって認証を行ってくれるプログラムのことで、 これは OpenSSH クライアントと通信して公開鍵認証を行います。 このさい、クライアントは認証エージェントとサーバの間で 暗号化された通信を自動的に中継します。

通常の公開鍵認証では、ユーザのパスフレーズによって復元された秘密鍵は一回しか認証に使われず、一度ログインしたあとは失われてしまいます。 これに対して認証エージェントは復元された秘密鍵を一定時間にわたってメモリ上に保持し、 何度も使うことができます。認証エージェントを使うと、ユーザはパスフレーズを最初に一度入力するだけでよく、何度もパスフレーズを入力するわずらわしさから解放されます。 ただし、この便利さは諸刃の剣にもなります。ユーザが認証エージェントに復元された鍵を保持させたままで放置しておくと、 秘密鍵のパスフレーズを知らない第三者でもサーバにログインできてしまうからです。 OpenSSH では、認証エージェントが復元された秘密鍵をディスクに保存せず、一定時間が経過すると自動的に復元された秘密鍵をメモリ上から消去することによって、この危険性を抑えています。


3.OpenSSHの設定

OpenSSH の設定ファイルの構成を示します

● OpenSSH の設定ファイルと鍵ファイル
  /etc/ssh/ssh_configOpenSSH クライアント設定ファイル (すべてのユーザ用)
  /etc/ssh/sshd_configOpenSSH サーバ設定ファイル
  /etc/ssh/ssh_host_keyホスト秘密鍵 (SSH1 プロトコル用)
  /etc/ssh/ssh_host_key.pubホスト公開鍵 (SSH1 プロトコル用)
  /etc/ssh/ssh_host_rsa_keyホスト RSA 秘密鍵 (SSH2 プロトコル用)
  /etc/ssh/ssh_host_rsa_key.pubホスト RSA 公開鍵 (SSH2 プロトコル用)
  /etc/ssh/ssh_host_dsa_keyホスト DSA 秘密鍵 (SSH2 プロトコル用)
  /etc/ssh/ssh_host_dsa_key.pubホスト DSA 公開鍵 (SSH2 プロトコル用)
  /etc/ssh/moduliDH 鍵交換アルゴリズムで使われる素数の一覧

OpenSSHの設定は「/etc/ssh/sshd_config」ファイルで行います。   viエディタで設定ファイルを開きます。

# vi /etc/ssh/sshd_config
# This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. Port 22  <---ssh で使うポート番号(デフォルト 22) #ListenAddress 0.0.0.0 #ListenAddress :: # Disable legacy (protocol version 1) support in the server for new # installations. In future the default will change to require explicit # activation of protocol 1 Protocol 2  <---ssh のバージョン 2 を使う # HostKey for protocol version 1 #HostKey /usr/local/etc/ssh_host_key # HostKeys for protocol version 2 HostKey /usr/local/etc/ssh_host_rsa_key HostKey /usr/local/etc/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 1024 # Logging # obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m PermitRootLogin no  <---root によるログインを禁止する StrictModes yes  <---キーを保管するディレクトリ等のパーミッションを検査 #MaxAuthTries 6 #MaxSessions 10 RSAAuthentication no  <---RSA による認証を禁止する (SSH1での公開鍵認証を禁止) PubkeyAuthentication yes  <---PublicKey による認証を許可する(SSH2での公開鍵認証) AuthorizedKeysFile .ssh/authorized_keys  <---公開鍵が保管されるファイル名 # For this to work you will also need host keys in /usr/local/etc/ssh_known_hosts RhostsAuthentication no  <---rhosts による認証を禁止する # similar for protocol version 2 HostbasedAuthentication no  <---ホストベースによる認証を禁止する # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes  <--- .rhosts を無視する # To disable tunneled clear text passwords, change to no here! PasswordAuthentication no  <---UNIXパスワード認証を禁止する PermitEmptyPasswords no  <---空パスワードは許可しない # Change to no to disable s/key passwords ChallengeResponseAuthentication no  <---チャレンジ・レスポンス認証 # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCreds yes # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. #UsePAM no  <---UNIXパスワード認証を禁止する #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no #X11Forwarding no  <---X11転送を許可するかどうか #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no #UsePrivilegeSeparation yes #PermitUserEnvironment no #Compression delayed ClientAliveInterval 60  <---クライアント生存チェック:一定時間レスポンスが無くても接続を切らないようにする #ClientAliveCountMax 3 #UseDNS yes #PidFile /var/run/sshd.pid #MaxStartups 10 #PermitTunnel no #ChrootDirectory none # no default banner path #Banner none # override default of no subsystems Subsystem sftp /usr/local/libexec/sftp-server # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # ForceCommand cvs server

設定を反映するためsshdを再起動

# /etc/init.d/sshd restart

4.SSHコマンド

1. 鍵ペアの作成

秘密鍵と公開鍵の鍵ペアを作成するには、ssh-keygen コマンドを使います。

● ssh-keygen コマンド構文
  ssh-keygen [オプション] [-f 鍵ファイル名]

● ssh-keygen オプション
 -b ビット長 鍵の長さを指定する。最低値は512ビット、初期設定値は1024ビット
 -f ファイル名 鍵のファイル名を指定する
 -p 新しく秘密鍵をつくるのではなく、すでにある秘密鍵ファイルのパスフレーズを変更します。まず秘密鍵の入っているファイルを訊かれ、古いパスフレーズを入力したあと、新しいパスワードを 2 回入力します。
 -t 鍵の種類 生成する鍵の種類を指定します。とりうる値として、プロトコル バージョン 1 で使う "rsa1" 、およびプロトコル バージョン 2 で使う "rsa" または "dsa" があります。
 -y OpenSSH 形式の秘密鍵ファイルを読み、 OpenSSH 形式の公開鍵を標準出力に表示します。

●ssh-keygenプロンプトでのオプション
 init=ファイル名初期プログラムを指定する
 root=デバイス名ルートファイルシステムを指定する
 singleシングルユーザモードで起動する
 ro読み取り専用でマウントする
 mem=数字m物理メモリを数字MBに指定する
 ランレベル指定したランレベルで起動する(1とsingleは同じ)

~/.ssh/ 以下に秘密鍵 (identity) と公開鍵 (identity.pub) のファイルが出来ています。


2. ssh-agent

ssh-agent は (RSA や DSA、ECDSA の) 公開鍵認証で使われる認証鍵を保持するプログラムです。基本的には、まずssh-agent を X セッションあるいはログインセッションの始めに起動させ、これ以外のすべてのウインドウやプログラムがその ssh-agent プログラムのクライアントとして起動するようにします。エージェントは環境変数を使うことにより、他のマシンにssh (1) を使ってログインするときに自動的に検出され、認証に利用できます。

a. ssh-agent の起動

ssh-agent は以下のようにして起動します。

$ ssh-agent bash

引数は起動するシェルの名前です。ここでは bash を指定していますが、それ以外のシェルでもかまいません。実行すると ssh-agent は指定されたシェルを起動し、自身もバックグラウンドで動作し続けています。


b. 秘密鍵の登録

次に、使用する秘密鍵を ssh-add コマンドで登録します。

$ ssh-add ~/.ssh/id_dsa

このときにパスフレーズを尋ねてきますので、指定した秘密鍵に合ったパスフレーズを入力してください。これで暗号化が解除された秘密鍵がメモリにストックされ、以降の SSH 接続では自動的にその情報が使用されます。もし複数の秘密鍵を使用している場合は、 ssh-add コマンドでいくつでも登録できます。
また、秘密鍵ファイルの指定を省略すると "~/.ssh/id_rsa", "~/.ssh/id_dsa", "~/.ssh/identify" が登録されます。

c. SSH 接続

サーバーに接続します。

$ ssh www.example.com

使用する秘密鍵が ssh-add で正常に登録されていれば、パスフレーズを入力することなく接続できます。これ以降、何回接続してもパスフレーズを尋ねられることはありません。もちろん、 scp など、 ssh 以外のプログラムでも有効です。

d. ssh-agent の終了

ssh-agent が起動したシェルを終了すれば、 ssh-agent も同時に終了します。exit コマンドで普通に終了すれば OK です。

e. ssh-agent の転送機能を利用する

ssh-agent のもうひとつの特徴的な機能として、認証の転送機能があります。通常、 ssh でリモートサーバーに接続して、そこからさらに別の SSH サーバーに接続するには、リモートサーバーのほうにログイン先の秘密鍵を置いておかなければなりません。しかし、この転送機能を使うと、大元のクライアントにある秘密鍵を使って、さらに別のホストにログインすることが可能です。
なにに便利かというと、例えばログイン先に別のサーバーから scp コマンドでファイルを転送したいとき、などです。
ssh-agent が起動していれば、接続のときに -A コマンドを付けて ssh コマンドを実行します。

$ ssh -A www.example.com

こうすると、ログイン先でローカルの ssh-agent に登録した秘密鍵が使えるようになります。後は、普通に ssh や scp で別のホストにログインすることができます。

f. ssh-agent の仕組み

最後に、 ssh-agent による認証処理の仕組みを簡単に説明しておきます。
ssh-agent が起動すると、 UNIX ドメインソケット(UNIX でプロセス間通信に使われる、ファイルシステムベースの通信経路)を作成し、その名前を環境変数 "SSH_AUTH_SOCK" に設定します。そして、 ssh コマンドなどが起動したときは、このソケット経由で通信を行い、秘密鍵が必要な認証の処理を ssh-agent に代行させます。シェルの環境変数は子プロセスからは変更できないため、代わりに新しいシェルを起動しているわけです。
このとき注意すべきなのは、root 権限があればすべてのユーザーの UNIX ドメインにアクセス可能なことです。つまり、他人が root ユーザーとしてログインできるマシンでは ssh-agent は使うべきではありません。 ssh-agent による認証を簡単に悪用されてしまいます。
また、必要がなくなったら ssh-agent を確実に終了させることも重要です。ここでご紹介した使い方ならシェルを終了した時点で ssh-agent も終了するため、通常は問題が起こることはないはずです。ただし、子プロセスとして起動されたシェルが強制終了されたときなどは注意が必要かもしれません。



b. GnuPG

PGP でも GnuPG でもハイブリッド暗号が使われています。これは、対称鍵暗号(共通鍵暗号)と公開鍵暗号を組み合わせて使うものです。 暗号化には対称鍵暗号を用いますが、その対称鍵暗号のセッション鍵は公開鍵暗号で暗号化して自動的にメッセージと結合されて送られます。受信者は公開鍵とペアの秘密鍵を用いてセッション鍵を取り出し、そのセッション鍵を用いてメッセージを復号化することになります。

GnuPG では基本的には対称鍵暗号として Triple DES、公開鍵暗号として ElGamal が使われます。また、オプションで他の方式も選べます。サポートされるアルゴリズムは gpg --version とすれば表示されます。 秘密鍵 としては CAST5、Blowfish Twofish などが使えるようです。一方、PGP 2.6 で使われていた公開鍵暗号の RSA と共通鍵暗号の IDEA は、PGP 5、PGP 6、GnuPG-1.0.1 のデフォルトの状態では使えません。


1.鍵ペア・失効証明書の作成

a.秘密鍵の取り扱い

暗号化された文書を復号するのに使う秘密鍵の取り扱いは十分に注意する必要があります。秘密鍵が盗まれてしまって もパスフレーズが分からなければ復号化はできないのですが、その安全性は非常に低下します。そのため、非常に機密 度が高い情報の復号化に使う秘密鍵はネットワークを介して盗まれないようにしなければなりません。 そのため次項の「鍵の生成」はネットワークから切り離した状態で行ってください。次項の「鍵の生成」を行うと普通 は
c:\Documents and Settings\usename\Application Data\gnupg
というホルダーに鍵束が作られます。secring.gpg というのが秘密鍵束なので、それを外部メディアに保存し、コンピ ュータから削除してからネットワークにつないでください。暗号化された文書を復号化するときにはネットワークから 切り離し、外部メディアにある secring.gpg をもとあった場所にコピーして復号化してください。
なお、それほど機密性の高くない文書の復号化に使う機密鍵についてはこれほどの神経を使う必要はありません。

b.鍵の生成

コマンドプロンプトで gpg --gen-key と入力し、鍵の生成を開始します。
まず入力を求められるのが鍵の種類です。「(1) DSAとElgamal既定)」を選択するので 何も入力しないでEnterを押してください。
次に鍵の長さを設定を求められます。2048 でいいの何も入力しないでEnterを押してください。
次に鍵の有効期限の指定が求められます。無期限でいいので何も入力しないでEnterを押してください。
Key does not expire at all
これで正しいですか? (y/N)
と尋ねられますので、y と入力してください。

$ gpg --gen-key gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. ご希望の鍵の種類を選択してください: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (署名のみ) (4) RSA (署名のみ) 選択は? 1 RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 要求された鍵長は2048ビット 鍵の有効期限を指定してください。 0 = 鍵は無期限 <n> = 鍵は n 日間で満了 <n>w = 鍵は n 週間で満了 <n>m = 鍵は n か月間で満了 <n>y = 鍵は n 年間で満了 鍵の有効期間は? (0) Key does not expire at all これで正しいですか? (y/N)

次に本名、電子メール、コメントなどを尋ねられますので入力してください。これにより鍵に名前のついたヘッダを追加することができます。本名は 5 文字以上の半角英数字を入力する必要がありますが、電子メール、コメントは何も書かなくても構いません。
次にパスフレーズを尋ねてきます。パスフレーズはスペースを含ませることができ長さの制限もないものと思って問題ありません。パスフレーズは大事なもので、これを忘れたら復号化はできません。
ここで乱数の生成が開始されます。乱数生成中はしばらくかかります。この時に他の作業をしていても問題ありません (作業をすることによりキーボードの入力やマウスの動きなども乱数発生に使用されます)。 鍵の生成が終了する

gpg: 鍵A49122E0を絶対的に信用するよう記録しました
公開鍵と秘密鍵を作成し、署名しました。
gpg: 信用データベースの検査 gpg: 最小の「ある程度の信用」3、最小の「全面的信用」1、PGP信用モデル gpg: 深さ: 0 有効性: 2 署名: 7 信用: 0-, 0q, 0n, 0m, 0f, 2u gpg: 深さ: 1 有効性: 7 署名: 0 信用: 0-, 0q, 0n, 0m, 7f, 0u gpg: 次回の信用データベース検査は、2008-07-07です pub 1024D/A49122E0 2007-02-11 指紋 = 105F 7790 6D00 3AFE 3118 85BA B0FC B285 A491 22E0 uid komori sub 2048g/53A4AE09 2007-02-11

のようなメッセージが出て終了します。

c.公開鍵の受け渡し

鍵を生成したら、それを使って暗号化する人に渡さなければなりません。 まず次コマンドを実行します。

$ gpg -o pubkey.asc -a --export userid

userid は鍵を作るときに入力した本名などの文字列(の一部)です。フォルダ gpg に pubkey.asc ができています。 pubkey.asc をフロピーディスクなどに入れて手渡すのが一番安全に渡す方法です。pubkey.asc の中身を電子メール に貼り付けて送ることも可能ですが、その場合は悪意をもった者があなたに成りすまして送ったものかどうかを、受け取った人が判断できない可能性があります。

d.他の人の公開鍵を入手する

他の人に暗号化したメッセージを送るのには相手の公開鍵を入手する必要があります。入手した公開鍵は鍵束に登録する必要があります。 pubkey.asc が入手した公開鍵とします。それを gpg フォルダにコピーし次コマンドを実行し、鍵束に入手した公開鍵を登録します。

$ gpg --import pubkey.asc

これで相手の人だけが秘密鍵で復号化できる暗号文を作れるようになります。

d.暗号化と署名(および復号化と検証)

次のコマンドを実行してみて下さい。

$ gpg -R komori -eas test.txt

まだ鍵署名もしていないし信用データーベースも更新していないので、警告メッセージが出るかもしれませんが無視してください。上の例では署名もするように指定しているのでパスフレーズの入力を求められます。鍵を作るときに指定したパスフレーズを入力してください(署名が必要ない場合は '-eas' の部分を '-ea' に変えてください)。 test.txt.asc というファイルができます。 次のコマンドを実行してみて下さい。

$ gpg test.txt.asc

test.txt.asc を復号化しようとしますが、あなたは私の秘密鍵を持っていないので復号化はできません。 自分にも復号化できるように暗号化するには次のコマンドを実行します。

$ gpg -R komori -R yourid -eas test.txt

yourid には先ほど作った鍵の本名などの文字列(の一部)を入れます。また、test.txt.asc というファイ ルができますので次のコマンドを実行します。

$ gpg test.txt.asc

今度は復号化(署名の検証も同時に行われる)ができるはずです。一般に

$ gpg -R user1 -R user2 -R user3 -R user4 -eas filename

で user1、user2、usser3、user4 の 4 人が復号化できる署名つき暗号ファイル filename.asc が作成されます。 この人数が多くなるとコマンドプロンプトに書くのが大変になります。そのときは次のようにします。

$ vi ./gpg/gpgoptions
armor hidden-recipient user1 hidden-recipient user2 hidden-recipient user3 hidden-recipient user4 hidden-recipient user5 hidden-recipient user6 hidden-recipient user7 hidden-recipient user8 hidden-recipient user9 hidden-recipient user10 hidden-recipient user11 hidden-recipient user12 hidden-recipient user13 hidden-recipient user14 hidden-recipient user15 hidden-recipient user16 hidden-recipient user17 encrypt sign

gpgoptions というファイル名で gpg フォルダ に保存してください。そして次のコマンドを実行すると 17 人が復号化できる暗号文 test.txt.asc が作成されます。 あなたはまだ 17 人もの公開鍵を鍵束に登録していないでしょうから、下のコマンドは実行しないで下さい。

$ gpg --options gpgoptions test.txt

ためしに,

------------------------------------------------------------- armor hidden-recipient komori hidden-recipient yourid encrypt sign ---------------------------------------------------------

を gpgoptions というファイル名で gpg フォルダに保存して上のコマンドを実行してみてください。 前に実行した

$ gpg -R komori -R yourid -eas test.txt

というコマンドと全く同じ働きをします。


e.Clear 署名

内容は秘密でないが、内容については確かに自分が書いたものであることを示すのには、暗号化はせずにClear 署名を用います。次のコマンドで Clear 署名ができます。

$ gpg --clearsign test.txt

これを実行するとパスフレーズの入力を求められ、正しく入力すると test.txt.asc というファイルができます。
本分の内容は全く暗号化されていませんが下のほうに署名がついています。 次のコマンドでこの署名を検証することができます。

$ gpg test.txt.asc


2.公開鍵によるファイルの暗号化と復号化

a. 鍵束 (keyring)とは

公開鍵暗号を使って暗号文をやりとりしたり、署名を検証したりするには、自分の公開鍵を公開したり、相手の公開鍵を知る必要があります。このとき利用する公開鍵をまとめて入れておくのが、鍵束 (keyring) です。
GnuGP を使う場合、例えば UNIX では、鍵束はホームディレクトリの下の ~/.gnupg というディレクトリの中の pubring.gpg というファイルになります。


b. 暗号化と復号化

【 暗号化 (encryption) 】

例えば file という名前のファイルを暗号化しようと思った場合は

$ gpg -e -r user_id file

とします。file.gpg という暗号化されたファイルができます。user_id の部分には、送る相手の鍵の USER ID を指定します。 これについては、USER ID の指定を参照して下さい。以下では その指定部分は user_id と書くことにしておきます。 また、-r user_id を省略すると、USER ID を尋ねてきます。
メールに埋め込む場合など、アスキー形式で送る場合には、

$ gpg -ea -r user_id file

のようにオプションに a を追加してアスキー形式を指定します。 この場合のデフォルトの出力ファイルは file.asc です。
出力ファイルを変更するには o オプションを使います。これは他の場合でも同様。

$ gpg -ea -r user_id file -o output_file

【 複号化 (decryption) 】

暗号化する場合のオプション e を d に変えるだけです。アスキー形式でも同様です。

$ gpg -d file.gpg

結果は標準出力にでるので、複号したファイルを保存するには、

$ gpg -d file.gpg > file

とリダイレクトします。


c. 署名と検証

【 署名 】

$ gpg -s file $ gpg --sign file

file から署名つきメッセージを作成します。 上のようにタイプした後、メッセージに従ってパスフレーズを入力すれば、file.gpg という署名付きメッセージができます。(なお、こうしてできたファイル読むには

$ gpg -d file.gpg

ただし、これはバイナリファイルなので、メールで送るには不便です。そこで

$ gpg -sa file $ gpg --sign --armor file

とするとアスキー形式のファイルができます。ファイル名は file.asc になります。 しかし、テキストファイルに署名する場合は次のように本文はそのままの形で使うクリア署名を使うことが多いと思われます。

$ gpg --clearsign file

これにより、file.asc というファイルができます。この中身は元のテキストをそのまま含み、それにアスキー形式の署名を添付した形になっています。 さて、たとえクリア署名でも送信するファイルは元ファイルと同じではありませんし、署名は元ファイルと結合されています。 それでは不都合な場合のために、元ファイルは完全に残したまま署名は別ファイルとする分離署名が用意されています。これを生成するには、

$ gpg -b file $ gpg --detach-sig file

などとします。署名ファイルはデフォルトでは file.sig になります。もちろん次のようにしてアスキー形式にすることもできます。

$ gpg -ba file

この場合の署名ファイルはデフォルトでは、file.asc というファイル名になります。

【 検証 】

署名を検証する時は、

$ gpg --verify file

とします。これは標準の形式でもアスキー形式でも同様です。分離署名の場合は、file とその署名 file.sig に対して

$ gpg --verify file.sig file

とします(署名と元ファイルの順序に注意)。署名がアスキー形式でも同じです。


z. 出題範囲概要

概要 :
  • 公開鍵技術の基本を理解している。
  • 公開鍵技術を使用して、データおよび通信を保護できる。

詳細 :
  • OpenSSH クライアントの設定および利用ができる。
    ssh-keygen, ssh-agent, ssh-add
  • 主要な暗号化アルゴリズムと特徴を知っている。
    rsa, ecdsa, ed25519
  • SSHポート転送について理解している。
  • 基本的なGnuPGの設定および利用ができる。
    gpg, gpg-agent, ~/.gnupg/

  [ 例題 ] 


         

    www.it-shikaku.jp